Devices communicating over networks such as the Internet can utilize any of a number of different transport protocols including, for example, the Hypertext Transfer Protocol (HTTP) version 1.1, as such is described in the Internet Engineering Task Force (IETF) request for comment document RFC 2616, entitled: Hypertext Transfer Protocol —HTTP/1.1, the contents of which are hereby incorporated by reference in its entirety. The overhead of transport protocols such as HTTP is not viewed as a problem for wireline network communications. However, the same overhead is often viewed as a major performance burden in the wireless environment, which is far more sensitive to the amount of transmitted data.
When transmitting small packets of data, transport protocols such as HTTP can be swamped by the overhead associated with the inclusion of HTTP meta-data, as such may be included within fields of request headers. For example, a typical wireless device may send upwards of 800-900 bytes of request header information in each HTTP transaction. And such header information may represent 75% or more of the transmitted data in an HTTP request. As will be appreciated, a request header may include fields of information that define acceptable responses to the requests, including the media types, character sets, content codings, sets of preferred natural languages, and byte ranges of acceptable responses. In this regard, many request header fields typically do not change from request to request while in a browsing or other network communication session. The problem is that repeatedly transmitting the same data in a browsing or other network communication session makes the use of HTTP, when sending small packets, slow when compared to other transmission protocols such as the Wireless Session Protocol (WSP). As will be appreciated, the crossover point at which HTTP begins to outperform WSP is typically when the total packet size of transmitted data is at least approximately 10K bytes. However, most packets in the wireless environment are smaller then 10 K bytes.
One technique for client devices, such as wireless mobile stations, to reduce the overhead associated with request header fields in HTTP transmissions is to cache such headers during a communication session between client devices. For example, protocols such as Wireless Application Protocol (WAP) and Wireless Session Protocol (WSP) define clients and servers communicating in discrete communication sessions. In initiating a communication session, a client may send a number of header fields to a server or proxy. The header fields may then be cached by the other system element(s) for reference during the communication session. Such a technique is adequate for reducing the overhead of HTTP transmissions, but techniques such as those specified by WAP and WSP are based upon communication sessions between clients and servers. In this regard, to initiate each subsequent communication session between the same client and server, the initiating client must send the header fields to the responding client or proxy, with the other system element(s) again caching the header fields for the respective communication session.
Another typical way for client devices to eliminate the overhead associated with request header fields in HTTP transmissions, such as those defining acceptable responses, is simply not to send them. In lieu of conventional request header fields that define the content that is acceptable to a client device, the client device may send HTTP requests including a single Accept header that accepts everything (i.e., */*). And whereas such a technique is adequate to reduce the overhead associated with HTTP transmissions, such a technique has drawbacks. In this regard, by accepting all content to the client device, the client device will often receive content that it cannot process. In such instances, much, if not all, of the savings associated with small headers is lost when content is transmitted to the terminal that must then be rejected.